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Abstract 


This document clarifies the Zero Window Probes (ZWPs) described in 
RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). 
In particular, it clarifies the actions that can be taken on 
connections that are experiencing the ZWP condition. Rather than 
making a change to the standard, this document clarifies what has 
been until now a misinterpretation of the standard as specified in 
RFC 1122. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6429. 
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Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 

Section 4.2.2.17 of "Requirements for Internet Hosts -- Communication 


Layers" [RFC1122] says: 


"A TCP MAY keep its offered receive window closed indefinitely. 
As long as the receiving TCP continues to send acknowledgments in 
response to the probe segments, the sending TCP MUST allow the 
connection to stay open. 


DISCUSSION: 
It is extremely important to remember that ACK (acknowledgment) 


segments that contain no data are not reliably transmitted by 
TORT: 
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Therefore, zero window probing needs to be supported to prevent a 
connection from hanging forever if ACK segments that re-open the 


window are lost. The condition where the sender goes into the Zero 
Window Probe (ZWP) mode is typically known as the ’persist 
condition’. 


This guidance is not intended to preclude resource management by the 
operating system or application, which may request that connections 
be aborted regardless of whether or not they are in the persist 
condition. The TCP implementation needs to, of course, comply by 
aborting such connections. If such resource management is not 
performed external to the protocol implementation, TCP 
implementations that misinterpret Section 4.2.2.17 of [RFC1122] have 
the potential to make systems vulnerable to denial-of-service (DoS) 
[RFC4732] scenarios where attackers tie up resources by keeping 
connections in the persist condition. 


Rather than making a change to the standard, this document clarifies 
what has been until now a misinterpretation of the standard as 
specified in RFC 1122 [RFC1122]. 


Section 2 of this document describes why implementations might not 
close connections merely because they are in the persist condition, 
yet need to still allow such connections to be closed on command. 
Section 3 outlines a simple attack on systems that do not 


sufficiently manage connections in this state. Section 4 concludes 
with a requirements-language clarification to the RFC 1122 
requirement. 

1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


2. Discussion of RFC 1122 Requirement 


Per [RFC1122], as long as the ACKs are being received for window 
probes, a connection can continue to stay in the persist condition. 
This is an important feature, because applications typically would 
want the TCP connection to stay open unless an application explicitly 
closes the connection. 


For example, take the case of a user running a network print job 
during which the printer runs out of paper and is waiting for the 
user to reload the paper tray (user intervention). The printer may 
not be reading data from the printing application during this time. 
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Although this may result in a prolonged ZWP state, it would be 
premature for TCP to take action on its own and close the printer 
connection merely due to its lack of progress. Once the printer's 
paper tray is reloaded (which may be minutes, hours, or days later), 
the print job needs to be able to continue uninterrupted over the 
same TCP connection. 


However, systems that misinterpret Section 4.2.2.17 of [RFC1122] may 
fall victim to DoS attacks by not supporting sufficient mechanisms to 
allow release of system resources tied up by connections in the 
persist condition during times of resource exhaustion. For example, 
take the case of a busy server where multiple (attacker) clients can 
advertise a zero window forever (by reliably acknowledging the ZWPs). 
This could eventually lead to resource exhaustion in the server 
system. In such cases, the application or operating system would 
need to take appropriate action on the TCP connection to reclaim 
their resources and continue to maintain legitimate connections. 


The problem is applicable to TCP and TCP-derived flow-controlled 
transport protocols such as the Stream Control Transmission Protocol 
(SCTP). 


Clearly, a system needs to be robust to such attacks and allow 
connections in the persist condition to be aborted in the same way as 
any other connection. Section 4 of this document provides the 
requisite clarification to permit such resource management. 


3. Description of One Simple Attack 


To illustrate a potential DoS scenario, consider the case where many 
client applications open TCP connections with an HTTP [RFC2616] 
server, and each sends a GET request for a large page and stops 
reading the response partway through. This causes the client’s TCP 
implementation to advertise a zero window to the server. For every 
large HTTP response, the server is left holding on to the response 
data in its sending queue. The amount of response data held will 
depend on the size of the send buffer and the advertised window. If 
the clients never read the data in their receive queues and therefore 
do not clear the persist condition, the server will continue to hold 
that data indefinitely. Since there may be a limit to the operating 
system kernel memory available for TCP buffers, this may result in 
DoS to legitimate connections by locking up the necessary resources. 
If the above scenario persists for an extended period of time, it 
will lead to starvation of TCP buffers and connection blocks, causing 
legitimate existing connections and new connection attempts to fail. 


A clever application needs to detect such attacks with connections 
that are not making progress, and could close these connections. 
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However, some applications might have transferred all the data to the 
TCP socket and subseguently closed the socket, leaving the 
connections with no controlling process; such connections are 
referred to as orphaned connections. These orphaned connections 
might be left holding the data indefinitely in their sending gueue. 


The US Computer Emergency Readiness Team (CERT) has released an 
advisory in this regard [VU723308] and is making vendors aware of 
this DoS scenario. 


4. Clarification Regarding RFC 1122 Requirements 


As stated in [RFC1122], a TCP implementation MUST NOT close a 
connection merely because it seems to be stuck in the ZWP or persist 
condition. Though unstated in RFC 1122, but implicit for system 
robustness, a TCP implementation needs to allow connections in the 
ZWP or persist condition to be closed or aborted by their 
applications or other resource management routines in the operating 
system. 


An interface that allows an application to inform TCP on what to do 
when the connection stays in the persist condition, or that allows an 
application or other resource manager to query the health of the TCP 
connection, is considered outside the scope of this document. All 
such techniques, however, are in complete compliance with TCP 
[RFCO793] and [RFC1122]. 


5. Security Considerations 


This document discusses one system security consideration that is 
listed in "Guidelines for Writing RFC Text on Security 
Considerations" [RFC3552]. In particular, it describes an 
inappropriate use of a system that is acting as a server for many 
users. That use and a possible DoS attack are discussed in 
Section 3. 


This document limits itself to clarifying RFC 1122. It does not 
discuss what can happen with orphaned connections and other possible 
mitigation techniques, as these are considered outside the scope of 
this document. 
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